Event Driven Architecture is a form of Enterprise Systems.
In an event-driven architecture, a notable thing happens inside or outside your business, which disseminates immediately to all interested parties (human or automated). The interested parties evaluate the event, and optionally take action. The event-driven action may include the invocation of a service, the triggering of a business process, and/or further information publication/syndication.
Define EDA: is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.
An event can be defined as "a significant change in state." For example, when a consumer purchases a car, the car's state changes from "for sale" to "sold". A car dealer's system architecture may treat this state change as an event to be detected, produced, published and consumed by various applications within the architecture.
From Wikipedia
Development of Event Driven Architecture still requires consideration of how to react if an event does not occur. For example, if a system requires an interface from several another systems providing similar information and it is designed that middleware should receive the information from the various systems - manipulate the data - create and send the combined file to the receiving system - it is imperative that consideration is made on how to react if one of the feeder systems does not send a file to middleware especially if there is time sensitivity around when the receiving system needs the information. To illustrate this, consider a time recording system that needs employee's schedules to calculate their pay. If the employee's can be scheduled in a variety of scheduling systems, it will be necessary for middleware to receive and combine files from all of the scheduling systems then create a cohesive schedule file for the time system. The time system must have received and loaded all schedule information prior to the employee working. If one of the scheduling systems experience issues that prevent it from sending a file, middleware must have a deadline in which it proceeds with the scheduling information it has received and send the file to the time systems even though it has not received one of the feeder files. The event-driven architecture would be created to say - as soon as all scheduling files are received - evaluate information and create schedule file for time system. A deadline must be in place to say at 2:00 am if the evaluate/create file process has not yet begun - start process with information already received. As it is more desirable to have all of the information, there is probably an alarm in place - to notify specific individuals if a file has not been received by 1:00 am.
Event Driven Architecture is a form of Enterprise Systems.
In an event-driven architecture, a notable thing happens inside or outside your business, which disseminates immediately to all interested parties (human or automated). The interested parties evaluate the event, and optionally take action. The event-driven action may include the invocation of a service, the triggering of a business process, and/or further information publication/syndication.
Define EDA: is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.
An event can be defined as "a significant change in state." For example, when a consumer purchases a car, the car's state changes from "for sale" to "sold". A car dealer's system architecture may treat this state change as an event to be detected, produced, published and consumed by various applications within the architecture.
From Wikipedia
Development of Event Driven Architecture still requires consideration of how to react if an event does not occur. For example, if a system requires an interface from several another systems providing similar information and it is designed that middleware should receive the information from the various systems - manipulate the data - create and send the combined file to the receiving system - it is imperative that consideration is made on how to react if one of the feeder systems does not send a file to middleware especially if there is time sensitivity around when the receiving system needs the information. To illustrate this, consider a time recording system that needs employee's schedules to calculate their pay. If the employee's can be scheduled in a variety of scheduling systems, it will be necessary for middleware to receive and combine files from all of the scheduling systems then create a cohesive schedule file for the time system. The time system must have received and loaded all schedule information prior to the employee working. If one of the scheduling systems experience issues that prevent it from sending a file, middleware must have a deadline in which it proceeds with the scheduling information it has received and send the file to the time systems even though it has not received one of the feeder files. The event-driven architecture would be created to say - as soon as all scheduling files are received - evaluate information and create schedule file for time system. A deadline must be in place to say at 2:00 am if the evaluate/create file process has not yet begun - start process with information already received. As it is more desirable to have all of the information, there is probably an alarm in place - to notify specific individuals if a file has not been received by 1:00 am.
EDA Companies:
Click the link below for an analysis of Complex Event Processing.
http://acg5405.wikispaces.com/space/showimage/idc-aptsoft-profile%5B1%5D.pdf%7Chttp://acg5405.wikispaces.com/space/showimage/idc-aptsoft-profile%5B1%5D.pdf|http://acg5405.wikispaces.com/space/showimage/idc-aptsoft-profile%5B1%5D.pdf|http://acg5405.wikispaces.com/space/showimage/idc-aptsoft-profile[1].pdf